For regular voice calls in a signaling system 7 (SS7)-based network, such as the public switched telephone network (PSTN), a bearer channel for the call is reserved in the forward direction from the originating node to the terminating node before the called party is alerted to the call. Only after the bearer channel has been established between the originating node and the terminating node is the called party's phone rung so that he or she may answer the call. For example, when a calling party dials a telephone number, an originating service switching point (SSP) sends an ISDN user part (ISUP) initial address message (IAM) to reserve a trunk circuit from the originating SSP to the destination SSP. Once the destination SSP receives the IAM, the destination SSP may return an address complete message (ACM) in the backward direction to indicate that the trunk circuit between the originating SSP and the destination SSP has been reserved. The destination SSP also rings the called party to indicate an incoming call. When the called party answers (i.e., goes off hook), the destination SSP returns an answer message (ANM) to the originating switch and begins billing the call.
For more advanced calls, such as those requiring calling party interaction with an automated system before connection, the call is initially connected to an interactive voice response (IVR) application before connecting the call to a called party. In an IVR application, media may be received from the calling party and, in response, audio may be generated by the IVR for navigating a series of audio menus/prompts. Typical examples of early media generated by the calling party in an IVR call include voice commands and dual tone multi-frequency (DTMF) tones (i.e., touch tones), and typical examples of early media generated by the IVR application include pre-recorded or dynamically generated audio, such as audio menu(s) and/or prompt(s). In a call that requires early IVR interaction, the call arrives at a destination SSP and is connected to the IVR application instead of ringing the called party in order to provide a period for interacting with the calling party before connecting the call to the called party. Because these types of calls involve media interaction early in the process of connecting a call to the called party (i.e., before ringing the called party), they are referred to herein as “early media” calls. As used herein, the term “early media” refers to media (e.g., data, audio, and/or video) that is exchanged between the calling party and another entity separate from the called party before a media connection is accepted by the called party.
In contrast to PSTN call establishment where media trunks are set up as call signaling proceeds in a forward direction from the calling party, in session initiation protocol (SIP) networks, before a bearer channel is established, media negotiation must take place between the originating and terminating endpoints. For example, the session description protocol (SDP) may be used in conjunction with SIP or other higher layer protocols for conveying sufficient information for SIP endpoints to discover and participate in a multimedia session. SDP is more fully described in RFC 4566, which is incorporated by reference herein in its entirety.
One problem associated with providing early media in a SIP network is that SIP networks require a 2xx response to be sent from a user agent server (UAS) to a user agent client (UAC) before media can be exchanged. Because the 2xx response is triggered when a called party answers a call, and early media exchange typically occurs before the called party answers, early media is not possible without modifying basic SIP network functionality.
SIP procedures for early media are described in Internet Engineering Task Force (IETF) requests for comments (RFCs) 3959, 3262, 3264, and 3311, the disclosures of each of which are incorporated by reference herein in their entireties. One such procedure specified in RFC 3959 defines a new “early session” disposition type for SIP. The early session disposition type described in RFC 3959 defines an offer/answer model based on SDP wherein one session participant generates and sends an SDP offer message to another session participant (i.e., the answerer). The SDP offer includes the set of media streams and codecs the offerer wishes to use, along with the IP addresses and ports the offerer would like to use to receive the media. In response to receiving the offer, the answerer generates an answer which includes a matching media stream for each stream in the offer, indicating whether the stream is accepted or not, along with the codecs that will be used and the IP addresses and ports that the answerer wants to use to receive media.
Even though early media extensions have been defined for SIP networks, not all SIP entities support the early media extensions. For example, if a SIP endpoint supports the SIP early media extensions but a SIP user agent server does not support the early media extensions, early media will not work for a call involving the two entities. In another example, early media extensions will not work when a call crosses the PSTN boundary where the PSTN gateway does not support SIP early media extensions.
FIG. 1 is a network diagram illustrating the failure to provide early media to a SIP endpoint when a PSTN gateway does not support SIP early media extensions. Referring to FIG. 1, SIP user agent client (UAC) 100 is located in SIP/IMS network 102 and places a call to a subscriber located in PSTN 104. In this case, UAC 100 initiates an offer by sending SIP INVITE message 106 constituting SDP offer A to MGC/MG or softswitch 108 (hereinafter, “softswitch”). Softswitch 108 converts INVITE message 106 into ISUP IAM 110 and forwards IAM 110 to destination SSP 112. At this time, a bearer channel has been established between the media gateway component of softswitch 108 and SSP 112 because SSP 112 has received a valid IAM (i.e., IAM 110) and both the media gateway and SSP 112 have reserved a trunk circuit for the call. SSP 112 may then communicate with IVR IN SCP 114 in order determine the content of media 116 (e.g., an audio announcement) to be played over the bearer channel. For example, IVR IN SCP 114 may instruct SSP 112 or a separate media server (not shown in FIG. 1) to play an announcement over the established bearer channel.
However, in the example illustrated in FIG. 1, no bearer channel has yet been reserved between UAC 100 and softswitch 108 because softswitch 108 does not support SIP early media extensions. Accordingly, early media is not possible for the scenario illustrated in FIG. 1.
Accordingly, in light of these difficulties, a need exists for improved methods, systems, and computer readable media for early media proxying.